\section{Display Interaction with CMS Core \& Plugins}
\fancyfoot[C]{Display Interaction with CMS Core \& Plugins}
As Displays are aggregates of visual elements and code as specified in Section \ref{sec:displaymanagement}, Displays also allow access to CMS functionality in order to trigger internal processes, via the code-behind model that ASP.NET generally leverages. Unlike a simple page/Content request as detailed in Figure \ref{fig:DisplayCMSConnection}, an execution request can do many things.\newline

\subsection{Displays and Code-Behind}
The code-behind will rely heavily on CMS-internal machinery, instead of the code-behind itself. Having the codebehind perform more than functionality unique to the Display makes maintenance hard for developers, as functionality would be scattered among Displays. In maintainable designs, functionality should be centralized on the CMS or a Plugin.\newline

Note that this model also logically leaves Display aggregations with little unique functionality; thus in this document we make these assumptions:
\begin{enumerate}
\item All supersets of types of intellectual content (Content Types) have at least one Display to render them.
\item All Displays are tailored to access at least some of the Content Type's assets and attributes, if applicable.
\end{enumerate}
Thus, in this document we assume that for every class in the CMS, there is a Display that can appropriately display and/or access it, unless that class is a Display itself. If a class in the CMS doesn't come with a necessary Display, it's possible to create one as necessary for a task at hand.

\subsection{Flow of Code-Behind Execution}
Flow of execution for Display-initiated code-behind is illustrated in Figure \ref{fig:FrontendPluginCMSInteraction}; it follows this general pattern:
\begin{description}
\item[Request Processing]The code-behind performs operations on user input that allows it to formulate a request to the CMS system.
\item[CMS Request]The code-behind then sends a formal request to the CMS in general. It will always be formulated in terms of a CMS Core method call, or an existing Plugin's method call instead.
\item[CMS Processing]Plugins may perform their own processing, and make requests to the CMS and its API (detailed in Section \ref{sec:API}), while the CMS itself performs input processing and calls to the Data Layer.
\item[CMS Response]After execution on input has been completed, the CMS core system will perform the Display-Content mating as detailed in the latter part of Figure \ref{fig:DisplayCMSConnection} before sending the finished web page to the requesting user.
\end{description}

\begin{figure}[!ht]
  \centering
    \includegraphics[width=4in]{FrontendPluginCMSInteraction.eps}
  \caption{A swimlane flowchart detailing a request that engages Plugin functionality. Coincidentally, it executes CMS functionality, but leaves page rendering to the CMS.}
\label{fig:FrontendPluginCMSInteraction}
\end{figure}
